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Response to Office Action Filed on 6/16/2005 

1. Claims 1-2, 4-9, 1 1-27, 29-41 are presented for examination. 

Claim Rejections - 35 USC § 102 

2. The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the 
basis for the rejections under this section made in this Office action: 

A person shall be entitled to a patent unless - 

(a) the invention was known or used by others in this country, or patented or described in a printed 
publication in this or a foreign country, before the invention thereof by the applicant for a patent 

3. Claims 1-2, 4-9, 11-19, and 22-25 are rejected under 35 U.S.C. 102(a) as being 
unpatentable by Rune, US Patent #6,304,913. 

4. As per claims 1, 6, 7, and 8, Rune teaches the invention as claimed including a method 
and a system for DNS translation, where the client is provided with a plurality of servers and 
directed to the server with the most optimal path. Rune's teachings comprise of: 

a processor (Col 7, 20-25. Router (Inherent)); 

a memory, at least one of the processor and the memory being adapted for (Col 7, 20- 
25. Router (Inherent)): 

receiving a service request (Col 7, lines 9-13. Receives a service request); 

sending a plurality of packets in response to receiving the service request (Col 7, lines 7- 
13. Response to a request, DNS server sends a request), each of the plurality of packets 
identifying a different type of service via which to send the corresponding packet, wherein the 
type of service indicates a service provider (Col 7, lines 20-25. DNS server receives a plurality 
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of packets, each identifying a unique IP address and hop counts. Col 3, lines 24-28, Col 4, lines 
18-21. Unique IP addresses correlate to different servers.); and 

maintaining a mapping of each different type of service to an IP address, thereby 
enabling the service request to be processed via an IP address associated with a type of 
service identified in a first one of the plurality of packets to be received (Col 4, lines 17-22. DNS 
server maintains a mapping of the host name and IP addresses.). 

5. As per claims 9, 23, 24, and 25, Rune teaches the invention as claimed including a 
method and system for DNS translation, where the client is provided with a plurality of servers 
and directed to the server with the most optimal path. Rune's teachings comprise of: 

receiving a DNS request indicating a domain name for which an IP address is requested 
(Col 7, lines 9-10. DNS server receives a DNS translation request.); and 

transmitting a plurality of DNS responses in response to the DNS request (Col 7, lines 7- 
14. Host sends a DNS request. DNS server sends a second request.), each of the plurality of 
DNS responses being transmitted via a different path associated with a different type of service, 
wherein the type of service indicates a service provider (Col 7, lines 20-25. DNS server 
receives a plurality of packets, each identifying a unique IP address and hop counts. Col 3, lines 
24-28, Col 4, lines 18-21. Unique IP addresses correlate to different servers.). 

6. As per claim 2, Rune teaches the method as recited in claim 1 , wherein the service 
request is a TCP connection request or a DNS request (Col 7, lines 9-10. DNS request.) 
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7. As per claim 4, Rune teaches the method as recited in claim 1 , wherein the type of 
service indicates a specific network connection or domain (Col 3, lines 53-55. Regional 
networks or the international networks.). 

8. As per claim 5, Rune teaches the method as recited in claim 1, wherein maintaining the 
mapping comprises maintaining a plurality of A-records, each of the A-records having a type of 
service field adapted for indicating a type of service and wherein receiving the request 
comprises receiving a DNS A-record request (Col 4, lines 17-22; Col 4, lines 46-47; Col 7, lines 
8-11; Col 7, lines 18-20. Receives a request for DNS translation. DNS server maintains a 
mapping of the host name and IP addresses. Each IP address for the plurality of servers 
contains hop counts to the servers.). 

9. As per claim 11, Rune teaches the method as recited in claim 9, wherein each of the 
plurality of DNS responses includes a different one of a plurality of IP addresses, each of the 
plurality of IP addresses being mapped to a different type of service. (Col 7, lines 6-25. Plurality 
of responses includes the different IP addresses of the servers, where each response identifies 
a server located on different regions of the network.). 

10. As per claim 12, Rune teaches the method as recited in claim 9, wherein each of the 
plurality of DNS response has the same source and destination address (Col 7, lines 10-25. 
Each of the DNS responses are sent from the router to the DNS server.). 

11. As per claim 13, Rune teaches the method as recited in claim 9, further comprising: 
Providing a service identifier in each of the plurality of DNS responses, the service identifier 
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identifying a service, type of service, or service provider that is to be used to route the 
corresponding DNS response (Col 7, lines 18-20. DNS responses contain the hop counts 
associated with the IP addresses of the different servers.). 

12. As per claim 14, Rune teaches the method as recited in claim 9, wherein each of the 
plurality of DNS responses comprises a type of service field adapted for indicating a type of 
service to be used during next-hop based routing based on the type of service (Col 7, lines 18- 
20; Col 4, lines 17-21. DNS responses contain the hop counts for the IP addresses, where the 
hop counts are located in the IP header, where the responses are routed from different 
networks.). 

13. As per claim 15, Rune teaches the method as recited in claim 9, wherein receiving a 
DNS request comprises receiving a DNS A-record request and wherein transmitting a plurality 
of DNS responses comprises transmitting a plurality of A-records (Col 6, lines 4-6. Server 
receives a DNS request and transmits a plurality of IP addresses associated with the host 
name.). 

14. As per claim 16, Rune teaches the method as recited in claim 15, wherein each of the 
plurality of A-records includes different IP addresses that is mapped to a type of service, service 
or service provider (Col 4, lines 17-21; Figure 1B. DNS server maintains a plurality of different 
IP addresses associated with the host name. The IP addresses are of servers located in 
different regions of the Internet such as in different networks.). 
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15. As per claim 17, Rune teaches the method as recited in claim 16, wherein each of the 
plurality of A-records further includes a field adapted for identifying the type of service, service, 
or service provider (Col 4, lines 44-46. DNS responses include a plurality of IP addresses and 
the hop counts for the plurality of IP addresses in the header.). 

16. As per claim 18, Rune teaches the method as recited in claim 17, further comprising: 
Maintaining a table of A-records that includes the plurality of A-records (Col 5, lines 19-26. DNS 
servers maintain a plurality of A-records.). 

17. As per claim 19, Rune teaches the method as recited in claim 9, wherein transmitting a 
plurality of DNS responses comprises transmitting the plurality of DNS responses to a client 
DNS server associated with a client initiating the DNS request (Col 7, lines 9-10; 20-25. Client 
submits a DNS translation request. Router transmits a plurality of DNS responses to the DNS 
server. The DNS server transmits an IP address to the requesting client). 

18. As per claim 22, Rune teaches the method as recited in claim 9, wherein transmitting the 
plurality of DNS responses comprises transmitting the plurality of DNS responses via one or 
more intermediate routers configured to perform next-hop policy based on the type of service 
(Col 7, lines 6-25. Router transmits a plurality of responses, where each response identifies a 
server located on different regions of the network. Router performs hop count on the different 
servers, located on different regions of the network.)- 
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Claim Rejections - 35 USC § 103 

19. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 1 02 of this title, if the differences between the subject matter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 



20. Claims 20-21, and 26 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Rune in view of Bohannon, US Publication #2002/0112036 (Bohannon hereinafter). 



21 . As per claim 20, Rune teaches that the DNS server is configured to receive from the 
router a plurality of DNS responses and the hop counts of the responses. The DNS server 
identifies one of a plurality of DNS responses from the router and responds to the client with an 
IP address based on the smallest hop count (Col 7, lines 20-25). However, Rune does not 
teach that the client DNS server is configured to identify specifically a first one of the plurality of 
DNS responses to be received from the network device and to respond to the client with an IP 
address of the type of service identified in the first one of the plurality of DNS responses. 

22. Bohannon teaches of providing the optimum service to a client, where a first one of a 
plurality of responses received by the client is selected for service (Page 6, Paragraph 0130). 

23. It would have been obvious to one of ordinary skill in the art at the time the invention was 
made to combine the teachings of Bohannon and Rune because both teachings deal DNS 
translation and providing the fastest service to the client. Rune's system is to provide the 
fastest service to the client, thus the router performs a hop count to detect the closest server to 
the client As taught by Bohannon, it would also be desirable for Rune's invention to identify the 
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first of the plurality of responses because Bohannon teachings indicate that the response is the 
optimum, thus it would improve the system of Rune by making the invention more efficient. 

24. As per claim 21, Rune and Bohannon taught the method as recited in claim 20. Rune 
further teaches wherein the client DNS server is further configured to obtain the type of service 
from the first one of the plurality of DNS responses and obtain an IP address corresponding to 
the type of service from a mapping table (Col 4, lines 17-21; Col 7, lines 20-25. DNS server 
maintains a mapping of the host name and the IP addresses. DNS server obtains the hop 
counts of the plurality of IP addresses.). 

25. As per claim 26, Rune teaches substantially the invention as claimed including a system 
for DNS translation, where clients are provided with a plurality of servers and directed to the 
server with the most optimal path. Rune's invention comprises of: 

a network device adapted for receiving a DNS request indicating a domain name (Col 7, 
lines 7-14. DNS server receives a request. DNS server then sends another request.) for which 
an IP address is requested and transmitting a plurality of DNS responses, each of the plurality 
of DNS responses being transmitted via a different path associated with a different type of 
service, wherein the type of service indicates a service provider (Col 7, lines 6-25. Router 
transmits a plurality of responses, where each response identifies a server located on different 
regions of the network. Col 7, lines 20-25. DNS server receives a plurality of packets, each 
identifying a unique IP address and hop counts. Col 3, lines 24-28, Col 4, lines 18-21. Unique 
IP addresses correlate to different servers.); 
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one or more intermediate routers configured to perform next-hop policy based routing 
based on the type of services (Col 7, lines 18-20. Router performs hop count on the different 
server, where the servers are located in different regions of the network.); and 

a client DNS server associated with a client initiating the DNS request, the client DNS 
server being configured to identify one of the plurality of DNS responses to be received from the 
network device and to respond to the client with an IP address of the type of service identified in 
the first one of the plurality of DNS responses (Col 7, lines 7-25. Client initiates a translation 
request. DNS server receives a plurality of the DNS responses from the router, including hop 
counts of a plurality of IP addresses and identifies the service with the smallest hop count.). 

26. Rune teaches that the DNS server is configured to receive from the router a plurality of 
DNS responses and the hop counts of the responses. The DNS server identifies one of a 
plurality of DNS responses from the router and responds to the client with an IP address based 
on the smallest hop count (Col 7, lines 20-25). However, Rune does not teach that the client 
DNS server is configured to identify specifically a first one of the plurality of DNS responses to 
be received from the network device and to respond to the client with an IP address of the type 
of service identified in the first one of the plurality of DNS responses. 

27. Bohannon teaches of providing the optimum service to a client, where first response 
received by the client is selected for the service (Page 6, Paragraph 0130). 

28. It would have been obvious to one of ordinary skill in the art at the time the invention was 
made to combine the teachings of Bohannon and Rune because both teachings deal with DNS 
translation and providing the fastest service to the client. Rune's teachings is to provide the 
fastest service to the client, thus the router performs a hop count to detect the closest server to 
the client. As taught by Bohannon, it would also be desirable for Rune's system to identify the 
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first of the plurality of responses because Bohannon's teachings indicate that the response is 
the optimum, thus it would improve the system of Rune by making the invention more efficient. 

29. Claims 27, 30-41 are rejected under 35 U.S.C. 103(a) as being unpatentable over Rune 
in view of Alkhatib, US Patent #6,430,623, and Bohannon, US Publication #2002/0112036. 

30. As per claims 27, 39-41 , Rune teaches substantially the invention as claimed including a 
method for DNS translation and establishment of a connection using TCP, where the client is 
provided with a plurality of servers and directed to the server with the most optimal path (Col 8, 
lines 33-34). Rune's teachings comprise of: 

a processor (Col 7, 20-25. Router (Inherent)); 

a memory, at least one of the processor and the memory being adapted for (Col 7, 20- 
25. Router (Inherent)): 

receiving a service request from a client (Col 7, lines 9-13. Receives a service request.); 

sending a plurality of packets to the client via plurality of different paths, each of the 
plurality of paths corresponding to a type of service, wherein the type of service indicates a 
service provider (Col 7, lines 20-25. DNS server receives a plurality of packets, each identifying 
a unique IP address and hop counts. Col 3, lines 24-28, Col 4, lines 18-21. Unique IP 
addresses correlate to different servers.); and 

ascertaining the type of service via which packet received by the client was transmitted 
(Col 7, lines 20-25; Col 8, lines 33-34. Client selects the closest alternative server based on the 
smallest hop count. Packet contains the IP address of the selected server.); and 



31 . Rune does not specifically teach of: 
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a) Receiving a TCP connection request from a client; 

b) Sending a plurality of TCP acknowledgement packets. 

c) Receiving acknowledgement messages indicating receipt of acknowledgment of 
packets. Transmitting; 

d) Ascertaining the type of service via which TCP acknowledgement packet 
received was transmitted. 

32. Alkhatib teaches of domain name routing, using the TCP protocol, where a TCP 
connection request is send by a client and acknowledgement packets are transferred between 
the sender and receiver to establish a connection, wherein the acknowledgement packets 
comprises of the source address and the connection identifier (Col 8, lines 48-53; Col 9, lines 2- 

6). 

33. It would have been obvious to one of ordinary skill in the art at the time the invention was 
made to modify the teachings of Rune to include the teachings of Alkhatib regarding the TCP 
protocol because both inventions deal with domain name routing and the use of the TCP 
Protocol as the network model to establish network connections. Furthermore, the teachings of 
Alkhatib to send a TCP connection request and the transferring of acknowledgement messages 
would improve the teachings of Rune by specifically teaching how the TCP protocol operates in 
DNS routing, and doing so provides a reliable end-to-end network connection. 

34. Rune does not teach of providing an HTTP redirect to an IP corresponding to the type of 
service. 



35. Bohannon teaches of providing HTTP redirect to the type of service (Paragraph 0129; 
0130; 0133). 
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36. It would have been obvious to one of ordinary skill in the art at the time invention was 
made to combine the teachings of Bohannon and Rune because both teachings deal with DNS 
translation and providing the fastest service to the client. Rune's system is to provide the 
fastest service to the client, thus it would be desirable to provide a HTTP redirect in Rune's 
invention because Bohannon's teachings would improve the efficiency of Rune's invention by 
routing information to the optimal server. 

37. As per claim 30, Rune teaches of a plurality responses comprising of hop counts and the 
IP addresses of the plurality of servers (Col 7, lines 18-20). However, Rune does not 
specifically teach the method, wherein each of the plurality of TCP acknowledgement packets 
comprises a type of service field adapted for indicating a type of service, service, or service 
provider. 

38. Alkhatib teaches of TCP acknowledgement packets that comprise of the connection 
identifier and the address of the source (Col 8, lines 52-54; Col 9, lines 16-20.). 

39. It would have been obvious to one of ordinary skill in the art at the time the invention was 
made to modify the teachings of Rune to include the teachings of Alkhatib regarding the TCP 
protocol because both inventions deal with domain name routing and the use of the TCP 
Protocol as the network model. Furthermore, the teachings of Alkhatib to have TCP 
acknowledgement packets that comprise of the connection identifier and the address of the 
source would improve the teachings of Rune by specifically teaching of how the TCP protocol 
operates in DNS routing and doing so provides a reliable end-to-end network connection. 
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40. As per claim 31 , Rune teaches of responses comprising of IP addresses of the plurality 
of servers and the hop counts to the servers (Col 7, lines 18-20). Rune does not specifically 
teach the method, wherein each of the plurality of TCP acknowledgement packets comprises a 
type of service field adapted for indicating a type of service to be used during next-hop based 
routing based on the type of service. 

41 . Alkhatib teaches of TCP acknowledgement packets that comprise of the connection 
identifier, the address of the source, and an option field (Col 8, lines 52-67; Col 9, lines 16-20.) 

42. It would have been obvious to one of ordinary skill in the art at the time the invention was 
made to modify the teachings of Rune to include the teachings of Alkhatib regarding the TCP 
protocol because both inventions deal with domain name routing and the use of the TCP 
Protocol as the network model. Furthermore, the teachings of Alkhatib to have TCP 
acknowledgement packets that comprise of the connection identifier and the address of the 
source would improve the teachings of Rune by providing specific teachings of how the TCP 
protocol operates in DNS routing, and doing so provides a reliable end-to-end network 
connection. 

43. As per claim 32, Rune does not specifically teach the method, wherein each of the 
plurality of TCP acknowledgement packets includes a sequence number field, the method 
further comprising: Providing a sequence number in the sequence number field indicating an 
order in which the plurality of TCP acknowledgement packets are sent. 

44. Alkhatib teaches an invention for domain name routing, using the TCP protocol, where 
the acknowledgement packets transmitted between the clients and servers contain sequence 
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number fields for the tracking of the sequence of the segments exchanged between the sender 
and receiver (Col 9, lines 1-9). 

45. It would have been obvious to one of ordinary skill in the art at the time the invention was 
made to modify the teachings of Rune to include the teachings of Alkhatib regarding the TCP 
protocol because both inventions deal with domain name routing and the use of the TCP 
Protocol as the network model. The teachings of Alkhatib to provide a sequence number in the 
sequence number field indicating an order in which the plurality of TCP acknowledgement 
packets are sent would improve the teachings of Rune by providing specific teachings of how 
the TCP protocol operates, and the use of sequencing packets ensures the proper transmission 
of data packets between the client and server. Doing so would provide a reliable end-to-end 
network connection. 

46. As per claim 33, Rune does not specifically teach the method as recited in claim 32, 
wherein receiving an acknowledgement message from the client that indicates receipt of one of 
the plurality of TCP acknowledgement packets sent by the network device comprises: Receiving 
an acknowledgement message from the client including the sequence number of a first of the 
plurality of TCP acknowledgement packets received by the client. 

47. Alkhatib teaches of domain name routing using the TCP protocol, where the 
acknowledgement packets send between the clients and servers contain sequence number 
fields for the tracking of the sequence of the segments exchanged between the sender and 
receiver (Col 9, lines 1-9). 

48. It would have been obvious to one of ordinary skill in the art at the time the invention was 
made to modify the teachings of Rune to include the teachings of Alkhatib regarding the TCP 
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protocol because both teachings deal with domain name routing and the use of the TCP 
Protocol as the network model. Furthermore, the teachings of Alkhatib to receive an 
acknowledgement message from the client including the sequence number of a first of the 
plurality of TCP acknowledgement packets received by the client would improve the teachings 
of Rune by providing specific teachings of how the TCP protocol operates and including the 
sequence number ensures the proper transmission of data packets between the client and the 
server. Using the TCP protocol would provide a reliable end-to-end network connection. 

49. As per claim 34, Rune does not teach the method as recited in claim 33, wherein each of 
the plurality of TCP acknowledgement packets further comprises: A type of service field 
adapted for indicating a type of service, service, or service provider via which the corresponding 
acknowledgement packet is to be transmitted. 

50. Alkhatib teaches of domain name routing using the TCP protocol, where the 
acknowledgement packets send between the clients and servers contain a connection identifier 
and the IP address of the source (Col 8, lines 53-55; Col 9, lines 1-9; Col 9, lines 17-20). 

51 . It would have been obvious to one of ordinary skill in the art at the time the invention was 
made to modify the teachings of Rune to include the teachings of Alkhatib regarding the TCP 
protocol because both teachings deal with domain name routing and the use of the TCP 
Protocol as the network model. Furthermore, the teachings of Alkhatib to provide a type of 
service field adapted for indicating a type of service, service, or service provider via which the 
corresponding acknowledgement packet is to be transmitted would improve the teachings of 
Rune by providing specific teachings of how the TCP protocol operates, and using the TCP 
protocol would provide a reliable end-to-end network connection. 
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52. As per claim 35, Rune does not teach the method as recited in claim 34, further 
comprising: obtaining the sequence number from the acknowledgement message received from 
the client; determining a type of service associated with the sequence number; and ascertaining 
an IP address corresponding to the type of service. 

53. Alkhatib teaches of domain name routing using the TCP protocol, where the 
acknowledgement packets send between the clients and servers contain a sequence number 
field, a connection identifier, and the IP addresses of both the source and destination (Col 8, 
lines 53-55; Col 9, lines 1-20). 

54. It would have been obvious to one of ordinary skill in the art at the time the invention was 
made to modify the teachings of Rune to include the teachings of Alkhatib because the 
teachings of Alkhatib to obtain the sequence number from the acknowledgement message 
received from the client, determine a type of service associated with the sequence number, and 
ascertain an IP address corresponding to the type of service would improve the teachings of 
Rune by providing specific teachings of how the TCP protocol operates, and using the TCP 
protocol would provide a reliable end-to-end network connection. 

55. As per claim 36, Rune ateaches the method as recited in claim 35, wherein ascertaining 
an IP address corresponding to the type of service comprises: Performing a look up in a 
mapping table, the mapping table including a plurality of IP addresses, each of the plurality of IP 
addresses corresponding to a different type of service (Col 4, lines 17-21. DNS servers 
includes a lookup table for storing the host names and the IP addresses of the servers.). 
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56. It would have been obvious to one of ordinary skill in the art at the time the invention was 
made to combine the teachings of Rune and Alkhatib to include a mapping of the IP addresses 
to the different services because Rune's teachings would improve the system of Rune and 
Alkhatib by allowing the DNS server to select the optimum server of a plurality of servers for the 
requesting client. 

57. As per claim 37, Rune does not teach the method as recited in claim 32, wherein each of 
the plurality of TCP acknowledgement packets further comprises: A type of service field 
adapted for indicating a type of service, service, or service provider via which the corresponding 
acknowledgement packet is to be transmitted. 

58. Alkhatib teaches of domain name routing using the TCP protocol, where the 
acknowledgement packets send between the clients and servers contain a connection identifier 
(Col 8, lines 53-55; Col 9, lines 1-9). 

59. It would have been obvious to one of ordinary skill in the art at the time the invention was 
made to modify the teachings of Rune to include the teachings of Alkhatib regarding the TCP 
protocol because the teachings of Alkhatib to provide a type of service field adapted for 
indicating a type of service, service, or service provider via which the corresponding 
acknowledgement packet is to be transmitted would improve the teachings of Rune by providing 
specific teachings of how the TCP protocol operates, and using the TCP protocol would provide 
a reliable end-to-end network connection. 

60. As per claim 38, Rune and Alkhatib taught the method as recited in claim 32. Rune 
further teaches wherein each of the plurality of TCP acknowledgement packets further 
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comprises a type of service field adapted for indicating a type of service to be used during next- 
hop based routing based on the type of service (Col 7, lines 6-25. Router transmits a plurality of 
responses, where each response identifies a server located on different regions of the network. 
Router performs hop count on the different services). 

61. Claim 29 is rejected under 35 U.S.C. 103(a) as being unpatentable over Rune, Alkhatib, 
Bohannon, in view of Brendel, US Patent #6,182,139. 

62. As per claim 29, Rune does not teach the method as recited in claim 27, wherein the 
TCP connection request comprises a TCP packet having a synchronize flag set and wherein 
each of the plurality of TCP acknowledgement packets comprise a TCP packet having a 
synchronize flag set and an acknowledge flag set. 

63. Brendel teaches of a client-server TCP connection wherein when a client requests a 
connection, a synchronization and acknowledgement packets are sent to the client (Col 7, lines 
33-35). 

64. It would have been obvious to one of ordinary skill in the art at the time the invention was 
made to combine the teachings of Rune and Brendel because the teachings of Brendel to 
include having a synchronize flag set in the acknowledgement packet because both inventions 
are using the TCP model as the network layer would improve the teachings of Rune by 
specifically teaching how the TCP protocol operates, and Brendel's teachings would ensure the 
proper transmission of data packets by allowing the client and the server to recognize the 
transmitted data. 



Response to Arguments 
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65. Applicant argued that (1) Rune fails to disclose or suggest identifying a type of service 
(e.g. service provider) in each packet (e.g., DNS response) send, as claimed; (2) Rune fails to 
disclose maintaining a mapping of each different type of service (e.g., service provider) to an IP 
address; (3) Rune fails to disclose or suggest transmitting a plurality of DNS responses, each 
being transmitted via a different path associated with a different type of service; and (4) Zisapel 
does not disclose selecting a fastest route according to ISP, as claimed; and (5) Zisapel does 
not disclose that the service provider is not identified in the packets transmitted, as claimed. 

Examiner traverses the arguments: 

66. As to point (1), Rune teaches of a router that transmits hop counts and IP addresses to a 
DNS server. The router receives a plurality of IP addresses and the associated hop counts (Col 
7, lines 20-25). Since each the response provides different hop counts and IP addresses, 
where the IP addresses correlate to different servers, (Col 4, lines 18-21), Rune clearly teaches 
of identifying a type of service in each packet. 

Applicant also argued that Rune does not teach of identifying a type of service provider. 
Rune teaches of providing a system of regional networks, international networks (Col 3, lines 
53-54) and different data networks (Col 3, lines 57-60). Thus, Rune's teachings show that there 
are different types of servers and networks in the system. Rune further teaches of selecting the 
closest alternative server and providing the same service (Col 3, lines 24-28), which indicates 
that Rune's teaches of identifying a type of service provider. 

67. As to point (2), Rune teaches of maintaining a look-up table for storing host name and 
unique IP addresses of the alternative servers (Col 4, lines 18-22), where the servers are 
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located in different networks (Col 3, lines 24-28). Therefore, Rune teaches of maintaining a 
mapping of each different type of service providers. 

68. As to point (3), Rune teaches receiving a request by the DNS server, whereby the DNS 
server sends a second request (Col 7, lines 9-12). Rune also teaches of a router receiving the 
hop counts and a plurality of IP addresses (Col 7, lines 20-21) in response to the request by the 
DNS server. To have received the hop counts from the different IP addresses, the responses 
must have transmitted from different paths or else the hop counts would be the same for all the 
IP addresses. On column 7, lines 23-25, Rune teaches that the smallest hop count is selected, 
so Rune teaches that the responses were transmitted in different paths. 

69. As to point (4), as per claim 3, it is noted that the features upon which applicant relies 
(i.e., selecting a fastest route according to ISP.) are not recited in the rejected claim(s). 
Although the claims are interpreted in light of the specification, limitations from the specification 
are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 
1993). 

70. As per claim (5), Rune teaches of identifying a different type of service (Col 7, lines 20- 
25), where identifying involves selecting one of a plurality of servers located on different 
networks (Col 3, lines 24-28). The rejection in view of Zisapel is withdrawn due to Applicant's 
amendments. 
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Conclusion 

71 . Applicant's amendment necessitated the new ground(s) of rejection presented in this 
Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant 
is reminded of the extension of time policy as set forth in 37 CFR 1.136(a). 

A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS from the mailing date of this action. In the event a first reply is filed within TWO 
MONTHS of the mailing date of this final action and the advisory action is not mailed until after 
the end of the THREE-MONTH shortened statutory period, then the shortened statutory period 
will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 
CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, 
however, will the statutory period for reply expire later than SIX MONTHS from the date of this 
final action. 

72. Any inquiry concerning this communication or earlier communications from the examiner 
should be directed to Joshua Joo whose telephone number is 571 272-3966. The examiner can 
normally be reached on Monday to Friday 7 to 4. 

73. If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, John A. Follansbee can be reached on 571 272-3964. The fax phone number for 
the organization where this application or proceeding is assigned is 703-872-9306. 
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74. Information regarding the status of an application may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published applications 
may be obtained from either Private PAIR or Public PAIR. Status information for unpublished 
applications is available through Private PAIR only. For more information about the PAIR 
system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private 
PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). 

August 15, 2005 
JJ 




